The present invention relates to computer systems and particularly to emulation of one computer architecture (the “guest”) via software on the hardware platform of another computer architecture (the “host”).
In typical computer architectures, computer source code is compiled/assembled (at compile/assembly time) into executable object code. The executable object code is executed at execution time on the hardware under control of the operating system. In order for computer source code written for a native architecture to run as a “guest” on a different architecture called a “host” architecture, the host architecture employs an emulator. The emulator emulates the native architecture while actually executing as a guest on the host architecture.
Various methods have been employed for emulating a guest computer architecture via software on the hardware platform of a host computer architecture. The categories of emulation are static emulation or dynamic emulation. In static emulation, the emulation is performed prior to run-time and in dynamic emulation, the emulation is performed at run-time.
One type of static emulation system employs object code translation. The native object code that is compiled/assembled for a native system becomes the guest object code on a host system. The guest object code is translated in a manner that is similar to the way that original source code is compiled/assembled into the object code for the native system. In the emulation case, however, rather than starting with the original source code, the emulation starts with the previously compiled/assembled object code as prepared for the native system. The guest object code (the native object code on the host system) is passed through an emulator to form the translated object code. The translated object code is suitable for execution directly by the host system. Essentially, static emulation is a method of recompiling the native object code without using the original source code. The advantage of such static emulation is that the resulting translated object code can be optimized in much the same way that native object code is optimized when native object code is compiled/assembled from original source code. Unfortunately, it is not always possible to glean all the necessary information statically from the native object code alone that was available when the original source code was compiled/assembled from original source code.
Another method of static emulation is Application Programming Interface (API) mapping. This method of static emulation only applies to operating system code in which the API calls of the guest operating system are mapped to a host call or set of host calls that perform the equivalent function on the host system. The API mapping has a performance advantage since the host operating system software has been optimized for the host system. However, if the native and host systems are too dissimilar, then the desired mapping may not always be possible. Nevertheless, API mapping is a useful method for providing some degree of equivalent operating system functionality when used in conjunction with other forms of static or dynamic emulation.
Dynamic emulation is performed during run time. The main advantage of dynamic emulation is greater transparency to the user in that no pre-processing need be invoked by the user as is required for static emulation. A simple type of dynamic emulation uses an interpreter which fetches, parses, and decodes each guest instruction and responsively executes a routine to carry out the equivalent functions on the host system. The main disadvantage of an interpreter is one of low performance because of the significant overhead involved in processing every guest instruction each time it is executed. To mitigate the disadvantage of that overhead, a more advanced method of dynamic emulation sometimes called “JIT” (just-in-time) translation is employed.
In JIT dynamic emulation, the native object code is translated (similar to the static method), cached, and executed in piecemeal fashion, a small portion at a time. By translating only a small portion of guest object code that is likely to be executed next, the translation is performed in real time, essentially concurrently with the execution of the translated code. The translated code is cached (i.e. saved) to permit subsequent re-use without the need for re-translation. The initial translation overhead is therefore amortized over time, allowing the overall performance to approach that of static object code translation, especially within the most frequently used portions of the code. By using additional information regarding program behavior that can be gleaned at run-time, it is possible to optimize the translated code to obtain performance beyond that achievable with static translation alone.
Emulation frequently is used when a CISC architecture is emulated on a RISC architecture. A key difference between typical CISC and RISC architectures lies in the complexity of the memory access model that is supported. A defining characteristic of RISC architectures is the “load/store” memory model in which the only memory access primitives provided are simple aligned loads, stores, and atomic updates. By way of distinction, CISC architectures, such as S/390, support many more storage-referencing primitives of varying operand lengths with fewer restrictions on operand alignment. If the translated code resulting from translations from CISC architectures to RISC architectures fails to properly account for alignment variations existing in the CISC code, alignment faults occur upon execution of the translated code. The alignment fault processing during emulation is very costly in terms of wasted execution time.
One technique to guarantee avoidance of alignment faults is to use only 1-byte primitives so that proper byte boundary alignment always occurs for operands. Although using 1-byte primitives guarantees avoiding alignment faults in translated code, the use of only 1-byte primitives in translations is less efficient than necessary in most cases. The alternative, however, of always using larger primitives, such as 4-byte primitives, guarantees a large amount of wasted execution time required for processing alignment faults that necessarily occur with high frequency during execution of the translated code.
Some CISC instructions, such as the S/390 LM instruction, use byte-aligned operands which can be predictably translated in advance without creating a byte alignment problem in the translated code. Other CISC instructions, such as the S/390 MVC instruction, are unpredictable and use variable length operands which cannot be predictably translated in advance of execution of precedent instructions without creating a byte alignment problem in the translated code.
Instruction code for CISC architectures often employs indirect addressing where the actual address used for a particular CISC instruction is not determined until execution of a precedent CISC instruction executed just before that particular CISC instruction is executed. Translations of CISC instructions that occur before the execution of the precedent CISC instruction cannot know, for such CISC instructions, the byte size of the operands that result from execution of the precedent CISC instruction. Hence, the indirect addressing context used frequently in instruction code using CISC instructions presents the dilemma in connection with the translation of such CISC instructions of whether to use short primitives (such as 1-byte primitives) or long primitives (such as 4-byte primitives) in the translations of those CISC instructions. For such instructions, if short primitives are employed, then the translation is inefficient and if long primitives are employed, then execution of the translated code is inefficient. In either case the emulation is inefficient.
In order to take advantage of dynamic emulation, there is a need for improved dynamic emulators that help achieve the objectives of improved and more efficient computer system operation, particularly in the processing of variable length operands and other operations that create operand alignment problems.